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Abstract 


The Ground Data Systems Resource Allocation Process at the Jet Propulsion Laboratory (JPL) provides medium - and 
long-range planning for the use of Deep Space Network and Mission Control and Computing Center resources in support of 
NASA’s deep space missions and Earth-based science . Resources consist of radio antenna complexes located in 
California, Australia and Spain, and associated data processing and control computer networks at JPL. Until 1985, JPL 
used a manual planning process that was extremely labor intensive and provided a planning horizon of only two to three 
weeks. With approval of increasingly complex missions, a more efficient planning system was needed to optimize the use of 
supporting facilities, minimize contention among users, expand the planning horizon to several years and reduce manual 
labor. 

To support an improved planning methodology, a semi-automated system has been developed that not only achieves 
these objectives but also enhances scientific data return. This end-to-end system allows operations personnel to 
interactively generate, edit and revise allocation plans spanning periods of up to ten years based on the relative merit of 
mission events. 

An integral part of this system is a software system known as the Resource Allocation and Planning Helper (RALPH). 
RALPH merges the conventional methods of operations research, ride-based knowledge engineering and advanced data 
base stnictures. RALPH employs a generic, highly modular architecture capable of solving a wide variety of scheduling and 
resource sequencing problems. Because RALPH easily handles generic requirements, the system has had an important 
influence on the simplification and standardization of input requirements from all projects. Additionally, the system design 
provides adaptability to changing mission environments. 

The rule-based RALPH system has saved significant labor in the resource allocation process at JPL. Its successful use 
affinns the importance of establishing and applying event priorities based on scientific merit, and the benefit of continuity in 
planning provided by knowledge-based engineering. The RALPH system exhibits a strong potential for minimizing 
development cycles of resource and payload planning systems throughout NASA and the private sector. 


Resource Allocation Planning at 
the Jet Propulsion Laboratory 

The Ground Data Systems Resource Allocation 
Process was established at the Jet Propulsion 
Laboratory (JPL) for the purpose of efficiently manag- 
ing the use of ground data system resources. These 
resources include the Deep Space Network (DSN) and 
the Mission Control and Computing Center (MCCC). 

The DSN is a global network of three tracking and 
data communications complexes which support NASA 
interplanetary missions and Earth-based science. Each 
complex has a 70 meter (diameter) antenna, two 34 
meter antennas, and a 26 meter antenna. The four an- 


tennas are linked to a Signal Processing Center com- 
puter network at each complex. Each of the three Sig- 
nal Processing Centers is linked by high-speed and 
wideband circuits to the MCCC data systems residing 
at JPL. 

The MCCC is a centralized multimission data 
processing and control center. It has the resources re- 
quired for the successful conduct and control of all 
aspects of space flight missions and radio-based 
astronomical observations. These include performing 
real-time multimission operations, data processing and 
systems control, and non-real time computations, such 
as image processing and data records generation. 
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The JPL Flight Project Support Office (FPSO) is 
responsible for allocating DSN and MCCC ground 
data system resources for spacecraft tracking, 
communications and science activities. The output of 
the resource allocation process is plans for optimal use 
of the available system resources. These plans must 
support the requirements of all missions. As a mini- 
mum, survival support must be guaranteed to 
spacecraft whose missions have been granted exten- 
sions beyond their primary objectives. 

Understanding Planning Constraints 

Allocation plans are required to address the needs 
of all projects, each of which may be in different 
phases of their lifecycles: missions in flight, in pre-flight 
development or in advanced planning stages. Al- 
location plans must be based on a set of constraints 
consisting of viewperiods, project requests, and system 
resource requirements. Each of these constraints is af- 
fected by dynamic factors that influence the planning 
strategy from week to week, complicating the planning 
problem. 

A viewperiod is a time interval over which a 
spacecraft is in view of a particular station antenna, al- 
lowing tracking and communications with the 
spacecraft. The ground stations are spaced at intervals 
of about 120 degrees in longitude from one another, 
ensuring that a spacecraft will be in view of at least one 
ground station at any time as the Earth rotates. Thus, 
each antenna at a single complex will have a view- 
period for each spacecraft target at least once during 
each Earth rotation. The dynamics of each spacecraft 
flight path determine the exact time and duration of 
every viewperiod. 

Project requests come in two different forms. 
There are specific requests and generic requests. 
Specific requests cover critical, time-dependent events. 
Projects typically demand specific tracking coverage to 
compensate for restrictions imposed by viewperiods or 
flight paths. A planetary encounter is one such time- 
dependent event. This level of input severely reduces 
planning flexibility. 

Generic user requests tend to be non-time de- 
pendent. A project user will ask for a total amount of 
support and a broad class of equipment over an exten- 
ded time period. An example is the minimum antenna 
coverage necessary to ensure signal reception. 
Combinations of antennas may be required to pull in 
very distant signals. Minimum and maximum allowable 
activity separations is another typical requirement. At 


the most general level of input, a user requests the ful- 
fillment of project objectives within a specific time 
frame. Such generic requests afford the most latitude 
in planning equipment allocations for a particular win- 
dow of time. 

System requirements place another set of con- 
straints on the resource allocation process. Certain 
station equipment must undergo pre- and post-calibra- 
tion. Station crews typically require a minimum of half 
an hour separation between successive signal acquisi- 
tions to make these necessary configuration changes. 
Resource maintenance, downtime and unmanned 
periods also contribute to the complexity of the plan- 
ning problem. 

The Resource Allocation Problem 

From the inception of the Deep Space Network in 
1958 through early 1986, resource allocation was essen- 
tially a manual process. Even for typical tracking situa- 
tions, planning is a complex problem with many 
variables. The high level of complexity dictates that 
the solution be determined in a somewhat non-sys- 
tematic way that usually involves a great deal of human 
decision. In a joint effort with the DSN, MCCC, Flight 
Projects, and other users, FPSO established several 
teams to accomplish the goals of the resource alloca- 
tion process. 

The Joint Users Resource Allocation Planning 
Committee (JURAPC) includes the managers and 
scientists of all involved organizations. It functions to 
establish allocation policies and priorities and to 
review proposed support requirements, established 
plans, and requests to modify requirements. 

The Resource Allocation Planning Team (RAPT), 
a subcommittee of the JURAPC, is chartered to imple- 
ment established policies, gather support requirements, 
review resource allocation plans, establish event prior- 
ities and resolve conflicts through negotiations. The 
RAPT is the focal point for all contention studies and 
“what-iP’ feasibility studies. 

The Resource Analysis Team (RAT) consists of 
expert planners and analysts. The workhorse of the 
resource allocation process, it operates and maintains 
the tools necessary for production of plans and special 
studies, and for database administration. The RAT 
team leader also coordinates and mediates all RAPT 
meetings. 

Using the manual planning system, this labor-in- 
tensive approach to resource allocation was capable of 
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providing a planning horizon of only two to three 
weeks. The lack of a structured method for determin- 
ing feasible support led to the generation of allocation 
plans which did not adequately reflect user needs. As 
a result, many hours of negotiations per week were 
necessary in order to clear unforseen conflicts. 

Over the years, the number of approved missions 
has been growing and their data collection and 
transmission capabilities have been expanding. Com- 
pounding the problem, most of the DSN-supported 
spacecraft have proceeded in the same general direc- 
tions away from Earth, causing viewperiods to overlap 
considerably. Because of this overlap, the concentra- 
tion of requests for resources has caused an uneven al- 
location profile. It became imperative to develop a 
more efficient planning system to optimize the use of 
supporting facilities, minimize contention between 
users, expand the planning horizon to several years, 
and reduce manual labor. 

Development of a Software Tool 

JPL established a Design Team to develop a tool 
that gives the Resource Analysis Team the ability to 


achieve a more efficient planning system. This Design 
Team joined planning analysts and software developers 
in an environment that enhanced information exchange 
(Figure 1). This integration of operations and develop- 
ment provided a global view of the task. Operational 
goals and developmental capabilities were merged to 
create a software tool that assists in all facets of the re- 
source allocation process. It was named the Resource 
ALlocation Planning Helper, or RALPH. The rela- 
tionship of RALPH to the resource allocation process 
is illustrated in Figure 2. 

The Design Team established clear top-level goals 
for the RALPH system: 

• Generation of detailed resource allocation plans 

• Reduction of plan generation time 

• Reduction of user conflict negotiation time 

• Quick turn-around for special studies 

• Automation of resource selection 

• Allocation based on event prioritization 

Important new concepts were introduced to op- 
timize resource planning: 



Figure 1 - JPL Resource Allocation Planning Environment 
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Requirements: 


Output: 


Adv. Mission Planning 
Pre-Project DeveL 
Flight Projects 
Earth-based Science 
DSN/SFOC/MCCC 
NASA/JPL Mgmt 



* Review Priorities 

* Review Pkns 

* Modify Plans 

* Resolve Conflicts 


Figure 2 — JPL Mechanism of Resource Allocation 


• Maximization of science return, followed by 
optimization of resource utilization 

• Identification of the variance between resource 
allocation plans and the sum of the original 
requirements (e.g., NASA Support Plans) 

Implementation of these concepts would enable 
the planning analysts to better manage the resource 
allocation process and improve internal flight project 
planning and scheduling processes. Previous allocation 
techniques have been based on mission priority. Plan- 
ning analysts at JPL have pioneered the idea of levels 
of support based on scientific merit or “event” 
priority. This method gives project negotiators a clear 
understanding of the impact on science return caused 
by any compromises to the plan. 

It is a goal of the resource allocation process to 
create 100% conflict-free resource allocation plans. 
However, oversubscription of resources, as well as the 
viewperiod overlap problem, creates a situation such 
that requests can not be completely satisfied. RALPH 
allows the resource analysis team to provide project 
users with near-optimum resource allocation plans 
which meet all user requirements while clearly pin- 
pointing any remaining conflicts. It remains a human 
decision-making task for project users to jointly 
negotiate a final determination of acceptable conflict- 


free levels of support. The final product is then used 
for mission operations schedules. 

Accommodating the Project Lifecycle 

The resource allocation process was designed to 
accommodate project needs throughout the various 
phases of their lifecycles. For this reason the resource 
allocation process provides products for three distinct 
subprocesses: 

• Special studies 

• Long-range forecasting 

• Mid-range planning 

Special studies are generated throughout the 
project lifecycle. Approximately ten years before a 
proposed spacecraft launch, when a new project 
defines preliminary functional requirements for 
spacecraft design and equipment support, the 
Resource Analysis Team reviews those requirements in 
light of approved resource allocation plans and major 
events. These special studies provide valuable impact 
assessments early in the project lifecycle. 

At any time, projects may request special studies 
to assess the feasibilities of different planning options, 
such as the impact of moving spacecraft launch win- 
dows. If contention appears inevitable, it is identified 
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within the report, along with appropriate statistical 
analyses and recommendations for alleviating the con- 
flict. 

Between two to ten years before a project's launch, 
the feasibility of requirements is seriously considered. 
This is the first point at which all requirements, such as 
the Support Instrumentation Requirements Document, 
the NASA Support Plan and the Mission Support Plan, 
are brought together and considered in total. At this 
stage, the requirements contain sufficient detail to 
generate a resource allocation forecast. However, the 
information during this period is tentative and subject 
to change based on many different factors. Despite 
their tentative nature, these long-range forecasts 
provide valuable resource allocation overviews during 
the mission's planning phase. Forecasts assist in the 
process of enhancing science return and reducing user 
impact. In addition, they supply information that is in- 
strumental to advanced planning and resource loading 
studies. 

Mid-range planning occurs between eight weeks to 
two years before an event. The resource allocation 
phase of the project lifecycle occurs from two years to 
six months prior to an activity. During this period, 
resource allocation plans are provided to project users 
for mission sequence development. This period marks 
the beginning of the iterative human decision-making 
process of conflict resolution between all project users, 


conducted by the Resource Analysis Team in RAPT 
and JURAPC meetings. 

Between six months and eight weeks before a 
planned activity, all conflicts must be resolved. This 
period supports the operations phase of the project 
lifecycle. At eight weeks prior to launch, the DSN and 
MCCC are presented with detailed conflict-free 
resource allocation plans for real-time operations. 
Figure 3 is an overview of the resource allocation pro- 
cess. 

Certain products were identified to support each 
phase of the allocation process. These were selected 
as output candidates for the RALPH system design. 

Special Studies 

• Impact studies 

• Management overviews 

Long-Range Forecasting 

• Detailed long-range forecasts 

• Summaries and supporting analyses 

Mid-Range Planning 

• Detailed resource allocation plans 
1 • Conflict summaries 

• Resource loading summaries 
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Figure 3 — JPL Ground Data System Resource Allocation Process 
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Figure 4 - Hierarchical Tree Structure of Data Representation 


With top-level goals and products clearly defined, 
the next step was to model the processes of the 
resource allocation problem. 

Modeling Resource Allocation 

RALPH is implemented as an expert system that 
utilizes hierarchical tree structures. These tree struc- 
tures contain descriptions of resources, requirements 
and specific rules. Data within these structures are 
easily modified to represent new conditions (Figure 4). 

The formal analytical processing capabilities of 
Operations Research (OR) have been included in 
modules that solve problems of resource allocation. 
Other modules include rules for attribute assignment, 
constraint violation, event language entry, and syntax 
parsing of user support events. All of these modules 
form a generic section of code, called the Core 
Resource Allocation Modules (CRAM). Each CRAM 
module is designed to utilize the symbolic logic and 
predicate calculus of the tree structures. In this way, 
the synthesis of knowledge engineering and OR tech- 
nologies has proven to be a successful solution to the 
JPL resource allocation problem. 

The entire resource allocation problem can be 
decomposed into five functional steps. This five-rule 
set, initially proposed by Information Sciences, Inc. in 
the 1970’s, provides a paradigm of the way a human 
analyst solves an allocation problem. The steps are: 

1. Definition of user support goals and feasible sup- 
port descriptions 

2. Prioritization of feasible support 

3. Resource assignment 

4. Time assignment 


5. Plan verification and conflict resolution 

The five-rule set suggested the need for several 
software subsystems to support the resource allocation 
planning function. These subsystems, a requirements 
translator, a mid-range plan generator, a long-range 
forecast generator, text and graphics editors, and an 
output capability generator are linked to provide a 
linear data flow through the system (Figure 5). 

The requirements translator is a high-level lan- 
guage processor. User event support descriptions are 
entered through language syntax processing modules 
which prompt the operator for appropriate attribute 
entries. The event description syntax is stored as a 
string. User support events may have attributes such 
as duration of assignments, resource preferences, and 
temporal relationships. 

Priorities are assigned based on the scientific signi- 
ficance of the user events. This concept was originated 
by the Resource Allocation Planning Team as the best 
means of achieving maximum science return with 
limited data system resources. The priority system, 
depicted in Table 1, is applied to all users for planning 
purposes. In this numerical scheme, an assignment of 
“one” represents the highest priority. 

The plan and forecast generator subsystems parse 
syntax strings into standard event tree structures. The 
generator must then allocate resources and time to 
those events that are consistent with the resource 
assignment objects contained within the system under 
the following guidelines: 

• Fully satisfy each user event 

• Minimize conflict among users 

• Maximize resource utilization 
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To reduce the combinatorial complexity that is 
typically encountered in large-scale resource schedul- 
ing systems, the generator uses a two-pass approach. 
The first pass determines probabilistic profiles of 
resource usage determined by requirements, windows 
and hard constraints. The second pass uses these 
profiles to evaluate possible scheduling points for mini- 
mum conflict. It proceeds in order of event priority, 
transforming the probabilistic profiles into determinis- 
tic schedules. 

Finally, RALPH employs two types of resource as- 
signment editors for plan verification and conflict 
resolution. Change entries are verified by many of the 
same CRAM attribute validation modules used by the 
requirements translator for event object descriptions. 

When validating and enhancing allocation plans, 
planning analysts may use the RALPH graphics editor. 
This allows easy modification of the plan based on 
operator recognition of color-coded visual allocation 
patterns (Figure 6). 


Modifications may also be entered through the 
RALPH text editor. This editor is designed to mimic 
the manual paper process used in RAPT negotiation 
meetings. It consists of line listings of resource alloca- 
tions sorted by day of week, time and user. The paper- 
based process will soon be eliminated entirely in favor 
of computer-aided editing. 

Results 

The RALPH software is implemented on a DEC 
Micro VAX II customized with a GPX high-resolution 
graphics workstation. RALPH is fully operational, 
allowing the Resource Analysis Team to efficiently 
produce long-range forecasts and mid-range plans for 
the DSN and MCCC. The number of workhours re- 
quired to produce a one-week mid-range plan have 
been reduced from 25 hours of manual labor to five 
hours using the RALPH tool. Without RALPH, long- 
range forecasts were not possible. With RALPH, long- 
range forecasts have been enabled. 



Figure 5 - RALPH System Architecture 
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Table 1 - Definitions of Resource Allocation Event Priorities 


Priority 

Activity Period and Priority Criteria* 

Examples** 

1 

Spacecraft Emergency which Threatens 
Achievement of Primary Objectives 

Time Critical 

Determined in Real Time 

2 

Single Opportunity or One-time Event 
Manditory for Achievement of Primary Objectives 

Time Critical 

Launch 

Midcourse Maneuvers 
Planetary Near Encounter 
Some Scientific Events** 

3 

Irregular Events with Subsequent Opportunity 
Available Mandatory for Achievement of 
Primary Objectives 

Time Critical 

Trim Maneuvers 
Some Orbital Cruise** 

Some Interplanetary Cruise** 
Planetary Radar 

4 

Regular or Repeated Events 

Mandatory for Achivement of Primary Objectives 

Time Critical 

Telemetry Dumps 

Some Interplanetary Cruise** 

Some Orbital Cruise** 

5 

Not Mandatory for Achievement of 
Primary Objectives 

Time Critical 

Extended Mission 
Some Interplanetary Cruise** 
Planetary Radio Astronomy 
Some Orbital Cruise** 

6 

Mandatory for Achivement of 
Primary Objectives 

Not Time Critical 

Some Orbital Cruise** 

Some Interplanetary Cruise** 
Pulsar Rotation Constancy 

7 

Not Mandatory for Achivement of 
Primary Objectives 

Not Time Critical 

“Priority-6” for Extended Mission 


‘These criteria are subject to revision by the RAPT, but they have not been revised for a number of years. 
“Actual events as governed by the priority criteria would, of course, be more project-specific. 
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Figure 6 - The RALPH Graphic Editor Allows Interactive Fine-tuning of Plans 



Table 2 - 

Results from RALPH Implementation 

Item 

1986 

1989 

Mid-range plan 

25 hours 

5 hours 

(Savings: 104Q hrs/yr) 

Meetings per week 

3-4 

1 

(Savings: 6240 hrs/yr) 

Planning horizon 

3 months 

10 years 

Long-range forecast 

Impossible 

Possible 

User interface 

Informal 

Standardized 

Requirements 

Specific 

Generic 

Data dissemination 

Manual 

Electronic 

Quick-look studies 

Very difficult 

Now doing one/week 


The RAPT meetings have benefitted as a result of 
more efficient output products. Previously, three to 
four negotiation meetings were required each week to 
clear conflicts. The research process of formalizing the 
event model led to a well-defined interface structure 
between resource users and operations personnel. 
Even without any software implementation, this in- 
creased definition has led to a significant reduction in 
requirements generation and negotiation time among 
users. The addition of the RALPH tool has further 
reduced the conflict level to the extent that one meet- 
ing per week is sufficient (Table 2). 

There are several key factors that contributed to 
the successful implementation of the automated 
software tool. The formation of a Design Team, which 
merged operational users and software developers, was 
a catalyst for a better global understanding of the 
functionality that is the core of the resource allocation 
process. The merging of knowledge engineering and 
operations research methodologies, with the ap- 
plication of the five-rule paradigm, clearly defined the 
operational environment. All of these factors resulted 
in the creation of effective software. 

The RALPH software is highly data driven and 
modular. These features, combined with the generic 
designs of the data structures, make the RALPH sys- 
tem extremely easy to modify. Object attribute repre- 
sentations are readily updated by operations personnel 


to reflect a changing resource en- 
vironment without modification of 
the programs that use the data. The 
data structure and software 
modularity enable RALPH to cross 
problem boundaries and support re- 
lated tasks with minimal develop- 
ment effort. These features enable 
the Resource Analysis Team to 
respond quickly to requests for spe- 
cial studies and management 
reports. A typical statistical report 
output from the RALPH system is 
depicted in Figure 7. 

The evolution provided by the 
RALPH system from a forecast to 
an operational plan has provided an 
efficient utilization of limited ground 
data system resources. RALPH has 
affirmed the significance of estab- 
lishing and applying event priorities 
based on scientific merit and the 
benefit of continuity in planning 
provided by knowledge-based en- 
gineering. RALPH is designed as an expandable sys- 
tem to meet the needs of an evolving allocation 
process. With appropriate emphasis on problem 
understanding and representation, the same metho- 
dologies merged to build RALPH can be utilized to 
support a large class of resource allocation and plan- 
ning systems. The RALPH system exhibits strong 
potential for minimizing development cycles of 
resource and payload planning systems throughout 
NASA and the private sector. 
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Figure 7 - Example of output: contention by user 
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